home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 4941 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  6.0 KB

  1. Path: ifi.uio.no!usenet
  2. From: ludvigp@ifi.uio.no (Ludvig Pedersen)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: doubling pixels horizontally
  5. Date: 6 Mar 1996 18:52:33 GMT
  6. Organization: Dept. of Informatics, University of Oslo, Norway
  7. Message-ID: <5257.6639T1152T2935@ifi.uio.no>
  8. References: <4f4ibc$gl9@news.cs.tu-berlin.de> <591.6610T1165T2102@login.eunet.no><1045.6611T753T2256@vip.cybercity.dk><4faoe1$47@sunsystem5.informatik.tu-muenchen.de><2991.6612T1034T625@vip.cybercity.dk><576.6613T1070T1730@login.eunet.no><1257.6614T57T922@vip.cybercity.dk>
  9.       <1982.6617T1096T103@ifi.uio.no> <4gbjg3$104@sunsystem5.informatik.tu-muenchen.de>
  10.      <4518.6625T1142T92@ifi.uio.no> <4h4hv5$mnn@sunsystem5.informatik.tu-muenchen.de>
  11.     <2444.6635T982T1557@ifi.uio.no> <4hhjlv$5qb@sunsystem5.informatik.tu-muenchen.de>
  12. NNTP-Posting-Host: gymir.ifi.uio.no
  13. X-Newsreader: THOR 2.22 (Amiga;TCP/IP)
  14.  
  15. >|> >Maybe I'm the only one but I can read/build code much better that way.
  16. >|> >And I could read my code well :)
  17. >|> WOW!...do you have any super-natural powers? ;^)
  18. >grrrrrrrrrrrrrrr :) no that's just a subjective thing.
  19.  
  20. hehehe....sorry about that! (grin) I just couldnt resist. :-)
  21.  
  22. >Code gets more structured (grrr don't laugh ;) and though more overview.
  23. >Puting instructions next to each other which are related to each other
  24. >subq.w #1,a5 : cmp.w #0,a5 : bne loop ;out of data registers
  25. >just one structure level more, code gets 2 dimensional (blah:) like
  26. >in C code. And as asm needs more instructions than C, it needs the
  27. >2 dimensional format even more if you don't wanna lose overwiev. baeh!
  28. >:)
  29.  
  30. Asm was never design for it, and I don't think it looks good either.
  31.  
  32. >|> >|> On my A1200 7mb/sec is not copy speed but chip write speed.
  33. >|> >mhm, all people told me the blizzard will _copy_ 7mb/sec.
  34. >|> >a myth ?
  35. >|> I think so. But please show me the copy-loop and I'll test it.
  36. >could you please try movem.l (fast)+,d0-d7 and then 8 times move.l dn,(chip)+
  37. >?
  38.  
  39. I did tried a LOT of different loops and here is a small collection of
  40. the top 5 loops I tried. Acutally the result was a little better than I
  41. thought.
  42.  
  43. ALL DMA IS OFF!
  44.  
  45.  
  46. ;Speed: 5.640 MB/s
  47.  
  48.         move.l  (a0)+,d0
  49.         move.l  (a0)+,d1
  50.         move.l  (a0)+,d2
  51.         move.l  (a0)+,d3
  52.         move.l  (a0)+,d4
  53.         move.l  (a0)+,d5
  54.         move.l  (a0)+,d6
  55.         move.l  (a0)+,a2
  56.         move.l  (a0)+,a3
  57.         move.l  (a0)+,a4
  58.         move.l  (a0)+,a5
  59.         move.l  (a0)+,a6
  60.         move.l  d0,(a1)+
  61.         move.l  d1,(a1)+
  62.         move.l  d2,(a1)+
  63.         move.l  d3,(a1)+
  64.         move.l  d4,(a1)+
  65.         move.l  d5,(a1)+
  66.         move.l  d6,(a1)+
  67.         move.l  a2,(a1)+
  68.         move.l  a3,(a1)+
  69.         move.l  a4,(a1)+
  70.         move.l  a5,(a1)+
  71.         move.l  a6,(a1)+
  72.  
  73.  
  74.  
  75. ; Speed: 5.472 MB/s
  76.  
  77.         movem.l (a0)+,d0-d6/a2-a6
  78.         move.l  d0,(a1)+
  79.         move.l  d1,(a1)+
  80.         move.l  d2,(a1)+
  81.         move.l  d3,(a1)+
  82.         move.l  d4,(a1)+
  83.         move.l  d5,(a1)+
  84.         move.l  d6,(a1)+
  85.         move.l  a2,(a1)+
  86.         move.l  a3,(a1)+
  87.         move.l  a4,(a1)+
  88.         move.l  a5,(a1)+
  89.         move.l  a6,(a1)+
  90.  
  91.  
  92.  
  93. ; Speed: 5.472 MB/s
  94.  
  95.         movem.l (a0)+,d0-d6/a2-a6
  96.         movem.l d0-d6/a2-a6,-(a1)
  97.  
  98.  
  99.  
  100. ; Speed: 4.896 MB/s
  101.  
  102.         rept    16
  103.         move.l  (a0)+,(a1)+
  104.         endr
  105.         dbra    d7,.loop
  106.  
  107.  
  108.  
  109. ; Speed: 4.656 MB/s
  110.  
  111.         rept    16
  112.         move.l  (a0)+,d0
  113.         move.l  d0,(a1)+
  114.         endr
  115.  
  116.  
  117. >imho this should do 7mb/sec in the store part. if the movem
  118. >is very fast, you aproximate the 7mb/sec also doing copying.
  119. 7 Mb/s is not possible. Remember that you have to access the same data-bus to
  120. read from FastRam.
  121.  
  122. >On 020-14 it will be slower than normal copy, on 020-28 maybe already
  123. >faster (only theory!)
  124. >so we still need a test if it's faster than move.l (fast)+,(chip)+
  125. >|> Here is my results from bustest:
  126. >|>
  127. >|> BusSpeedTest 0.07 (mlelstv) Buffer:    16384 Bytes
  128. >|> ==================================================
  129. >|> loop overhead:      4.5ns
  130. >|> register move:     40.6ns
  131.  
  132. >huh ? a register move is 2 cycles. you got 24.63 MHz ?
  133.  
  134. Ehh..No, I have 50 mhz.
  135.  
  136. I tested it myself. (just to be sure)
  137.  
  138. I was able to do 24400000 register move's and 203300 dbra's per second.
  139.  
  140. A dbra is 3 times slower than a register move so that's 25.0 peek MIPS.
  141.  
  142. 1.000.000.000 ns / 25.009.900 = 39.98 ns
  143.  
  144.  
  145. Check you numbers, its correct!
  146.  
  147. >|> memtype   op      cycle      bandwidth
  148. >|> fast      readw   109.1ns   18.3MByte/s
  149. >|> fast      readl   137.6ns   29.1MByte/s
  150. >|> fast      readm   167.7ns   23.8MByte/s
  151.  
  152. >readm slower ? hmhmhmhm. nooo.
  153. Ohhh-yes.. Just look at the copy results.
  154.  
  155. >if you use enough regs it's faster on 020-14.
  156. >also reading from chip is faster with readm... mhmhm
  157.  
  158. >|> Please not that this is write-speed and NOT copy speed.
  159. >|> >|> I did a simple test and I was able to copy 4.9mb/sec from fastram to
  160. >|> >|> chipram on a 256 colors screen.
  161. >|> >what size ?  overscan, 320x256,320x200 ? pal ?
  162. >|> PAL-lowres, no overscan.
  163. >maybe you can write in 10 14-mhz cycle parts, i.e 5.672mb/sec theoretic
  164. >if no dma at all.
  165. Yes, write 5.6 MB/s to ChipRam with no DMA.
  166.  
  167. >|> >|> I don't get it??? ;) It is optimal. That was actually VERY easy.
  168. >|> >|> Remeber that we are taking about 2x2 without sprite-dithering!!
  169. >|> >either you misuse a plane as mask, so 128 colors only, or the 2x2
  170. >|> >routine is slower than 3pass, i.e. not optimal :)
  171. >|> The blitter uses only 2 passes and *is* optimal. And its 256 colors.
  172.  
  173. >hehe, 2 passes blitter is slower than 1 pass blitter ;)
  174. >there's a misunderstanding in the word "optimal".
  175. >while there realy might be no way to do faster the way you do,
  176. >there's another way to do it :) the other way has disadvantages
  177. >(monitor sideefects ;) though.
  178.  
  179. We support both 2xN sprite-dithering (1 pass) and normal 2xN (2 pass).
  180.  
  181. If your render-routine is 25 fps or slower using the 2 pass version
  182. doesnt matter at all in speed and framerate. You only get a better-looking
  183. display.
  184.  
  185. Can you explain about that monitor side-effects stuff you are talking about.
  186. Is this something new?
  187.  
  188.  
  189.  
  190. <sb>Ludde - Amiga Demo Coder
  191. <sb>Virtual Reality & Official Be developer
  192. <sb>ludvigp@ifi.uio.no
  193.  
  194.